Improve On-Demand Multicast Routing Protocol in Mobile Ad-Hoc Networks المتعذد حسب الطلب

Transcription

1 Improve On-Demand Multicast Routing Protocol in Mobile Ad-Hoc Networks تحسين بروتوكول التوجيه ODMRP في الشبكات الالسلكية المخصصة المتنقلة المتعذد حسب الطلب Dr. Intisar Al-Mejibli Informatics Systems Management Dept., University of Information Technology and Communications, Baghdad, Iraq Computer Networks and Communications, Abstract- Ad hoc wireless network is a dynamic reconfigurable wireless network with no dedicated infrastructure, which makes establishing stable route between two mobile nodes difficult task. This attributed to the mobility characteristic in nodes that resulting in changing the network topology frequently. On-Demand Multicast Routing Protocol ODMRP is a common multicast routing protocol designed for wireless ad hoc networks. The dominance of ODMRP comes from its simplicity, high ratio of packet delivery, and independency on a specific unicast protocol. The main rule that ODMRP based on is flooding the entire network with the multicast route request to establish routes of multicast group with forwarding group and to keep the membership of nodes up-to-date. On the other hand, using unicast messages in establishing multicast group is vulnerable to node failures that are common because of the ad hoc networks dynamic nature. This paper proposed an improvement to the available ODMRP which aims to reduce the number of required broadcasting and tackles node failure issue. It s used unicast messages instead of broadcasting to refresh the nodes membership information which achieved by using ROUTE record with each JOIN REQUEST sent by multicast source. Additionally, it is proposed sending leave message LEAVE MSG by any node intends leaving the multicast group or forwarding group to alert all related nodes to be ready of using alternative route. NS2 simulator is used to apply the suggested improvements. A comparison is conducted between the proposed enhancements and the ODMRP for validation purpose. The obtained results were promising. Keywords: Ad-Hoc; Multicast Routing Protocol; ODMRP. الخالصة ا شثىح ا الس ى ١ ح ا خصصح شثىح الس ى ١ ح لات ح إلعادج ا رشى ١ ا ذ ٠ ا ١ ى ع عذ ج د ت ١ ح ذحر ١ ح خصصح ا ٠ جع إ شاء ساس سرمش ت ١ اث ١ ا عمذ ا ر م ح ح صعثح. ٠ عز ر ه إ خصائص ا ر م ف ا عمذ ا ر أدخ إ ذغ ١١ ش ط ت ج ١ ا ا شثىح ف وث ١ ش األح ١ ا. تش ذ و ي ا ر ج ١ ا رعذد حسة ا ط ة تش ذ و ي ذ ج ١ شائع االس ع اي رعذد اإلسساي ص شثىاخ ا الس ى ١ ح ا خصصح. ١ ح تش ذ و ي ا ر ج ١ ا رعذد حسة ا ط ة ٠ أذ تساطر سثح ذس ١ ا حز ح ا عا ١ ح االسرمال ١ ح ع تش ذ و ي احاد االسساي. ا ماعذج ا شئ ١ س ١ ح ا ر ٠ سر ذ إ ١ ا تش ذ و ي ا ر ج ١ ا رعذد حسة ا ط ة إغشاق ا شثىح تأو ا تط ة طش ٠ ك اإلسساي ا رعذد إل شاء ساساخ ج عح اإلسساي ا رعذد ع ج عح إعادج ا ر ج ١ ا حافظح ع حذاثح عض ٠ ح ا عمذ. اح ١ ح أخش فإ اسرخذا سسائ اإلسساي األحاد ف إ شاء ج عح اإلسساي ا رعذد عشضح فش ا عمذج تسثة طث ١ عح ا ذ ٠ ا ١ ح شثىاخ ا خصصح. ذمرشح ز ا سلح ذحس ١ تش ذ و ي ا ر ج ١ ا رعذد حسة ا ط ة ا حا ا ز ٠ ذف إ ذم ١ عذد االسساي ا رعذد ا ط ب ٠ عا ج سأ ح فش ا عمذج. ح ١ ث ا ا ذسرخذ ا شسائ أحاد ٠ ح تذال ا ثث رحذ ٠ ث ع اخ عض ٠ ح ا عمذ تاسرخذا سج طش ٠ ك ع و ط ة ا ض ا ا شس لث صذس ا ثث ا رعذد. تاإلضافح إ ر ه ذمرشح ز ا سلح إسساي سسا ح غادسج لث أ عمذج ذعرز ذشن ج عح اإلسساي ا رعذد أ ج عح إعادج ا ر ج ١ ر ث ١ ج ١ ع ا عمذ راخ ا ص ح رى ع اسرعذاد السرخذا ساسا تذ ٠ ال. اسرخذا ظا ا حاواج NS2 رطث ١ ك ا رحس ١ اخ ا مرشحح. أجش ٠ د ماس ح ت ١ ا رحس ١ اخ ا مرشحح تش ذ و ي ا ر ج ١ ا رعذد ألغشاض ا رحمك ا صحح االلرشاح. وا د ا رائج ا ر ذ ا حص ي ع ١ ا اعذج.. 351

2 I. Introduction The world witnesses a great development in network technologies and applications, the demand on multicast networking service is increased due to its vital role in many applications especially in mobile ad hoc networks. Disaster discovery, search and rescue, automated battlefields and crowd control are an examples of applications where ad-hoc networks are used. A mobile ad-hoc network consists of wireless mobile nodes that featured with self-organize into a network to provide communication facility. Although, mobile ad-hoc network does not has fixed infrastructure or configuration, it can operate properly. The nodes in such network are dynamically linked in freeways, so the ad hoc networks is frequently changing and it s hard to determine the topology of this network. Additionally, these nodes have ability of broadcast by their nature. Further, these nodes have limitation in energy, bandwidth and reliability of communication which are significant factors that affects the performance of the entire mobile ad hoc network. Hence, ad hoc networks required routing protocols that take into their consideration the aforementioned limitation of such network and not using wired network routing protocols with little modification and adaptation as they not suit for ad hoc networks. There are several new approaches and novel ideas appeared to satisfy the new requirements. Wireless ad hoc networks are proper for multicasting because of their inherent broadcast capability. In wire network, always unicast routing infrastructure regarded as backbone of multicast routing, whereas the situation is different in wireless ad hoc networks. Several multicast routing protocols are stand alone and independent of unicast protocols. Typically, there are many multicast protocols of mobile ad hoc networks based on different strategies for instance Multicast Ad hoc On- Demand Distance Vector Routing (MAODV), Adaptive Demand-Driven Multicast Routing in Multi-Hop Wireless Ad Hoc Networks (ADMRP), Ad-hoc Multicast Routing Protocol (AM Route), Ad hoc Multicast Routing protocol utilizing Increasing id-number S (AMRIS), On-Demand Multicast Routing Protocol (ODMRP ) [1], The Core-Assisted Mesh Protocol (CAMP) and Forwarding Group Multicast Protocol (FGMP). ODMRP protocol is a simple on-demand multicast routing protocol and maintains a mesh based on soft state [2]. This research proposed improvement on ODMRP to reduce its overhead and facilitate it to overcome node failure. The rest of this paper is organized as follows: the related work is illustrated in section2. Section 3 explains the proposed routing protocol in details. Simulated model is described in section 4. Section 5 includes the analysis results. Conclusion is presented in Section 6. II. Related Work Many studies and researches have been accomplished which are aim improving the performance of on-demand multicast routing protocol. The following presents some of these researches: The authors in [3] suggested using ODMRP with Multipoint Relay (ODMPR-MPR). The proposed technique aims to efficiently fulfill the function of flooding in wireless networks. The ODMPR-MPR based on the following principle: periodically, a HELLO messages are sent by each node that includes a list of neighbors which node may receive packets from them. When neighbor s HELLO message is received by node N with list of neighbors including neighbor, node N set a flag named Hearable for the neighbor after it has added this neighbor to its neighbor set. Thus, the collection of HELLO messages provides node N with its 2-hop neighbor set. This technique aims reducing the redundant re-transmission number while a flooding packet is diffused throughout the entire network. This technique adds new control message which is neighbor s HELLO message that must sent periodically by each node in the entire network. Accordingly, excessive channel overhead is added to the ODMPR for example if a network includes 50 nodes, 50 HELLO messages with a list of neighbor will be generated periodically. 352

3 In [4] a modification is suggested to overcome perceived node failures that results from the dynamic nature of mobile ad hoc networks named (Reliable On-Demand Multicast Routing Protocol RODMPR). This achieved via rebroadcast received packets by subset of nodes which are not included on forwarding paths to their neighborhoods nodes. Forwarding decision is made by each node probabilistically. Hence, a redundant forwarding paths are created by keep rebroadcasting packets in order to circumvent failed links in the network. This proposal depend on rebroadcasting to keep additional forwarding paths which results in consuming the resource of network and energy of involved nodes. The authors in [5] proposed adding an extension to the ODMPR named Enhanced ODMRP (E- ODMRP). This extension includes suggesting two parts: first on-demand Quality of Service (QoS) and second scheme of stability depend on multicast routing (OQSMR). It supposes that, periodically, each node in the network must estimates the required parameters which contains the stability factor of node and link with bandwidth availability, and delays. Then using the estimated parameters to create database of neighbor stability and QoS in every node. The last sequence is using, route request/reply packets to construction the multicast path, and QoS with stability information. In another words, the factor of link/node stability, bandwidth and delays in route information cache of nodes, are used to maintain multicast route when location of node changed within the network or route failures are occurred. Consequently, this proposal append more overhead to the nodes and network in terms of processing time, packets flooding and management. In [6] a protocol is proposed based on the same principle of ODMRP. This proposal uses route request/reply packets to constructs the multicast mesh. Additionally, this technique maintained a database at every node which includes cache of routing information and link stability. Each node must multicast its database when the multicast request is received. The subset from forwarding nodes, which have link connectivity with high stability, are selected founded the stable paths in multicast group. A number of parameters for instance: distance among neighboring nodes consumed power, and the link quality, which is estimated using bit errors in the packet, are used to determine the link stability. There is no difference between the principle of this technique and the proposal presented in [4]. Both of them requires maintaining a database in each node in entire network to establish stable paths and avoid route failures whereas maintaining a database in each node means additional overhead to the node. The authors in [7] developed a stable multicast routing protocol (Stable On-Demand Multicast Routing Protocol SODMRP) takes into its consideration the energy of nodes. This proposal attempts increase routes stability by using energy information of nodes. It aims improving route stability, by selecting the most stable route using route weight function, through using residue energy of nodes to predict rout expiration time. This proposal needs to compute node energy with each received multicast request which means additional overhead to node. An improved of multicast routing protocol depend on ODMRP was presented in [8] named as IODMRP. In this protocol two factors are used to choose partial nodes in forwarding group, which are: forwarder's density and power state. Partial nodes are dynamic and only these partial ones relay packets. IODMRP presented a proposal to overcome the issue of increasing control overhead when the multicast group is increased. The authors in [9] presented Reduced Data Transmission ODMRP (RDTODMRP) routing algorithm that determine the multiple routs by considering the conditions of network for instance mobility speed movement and traffic load. This proposal attempts achieving efficient result by decreasing the unnecessary repeated routes with their data transmissions. In [10] new multicast protocol was proposed which based on ODMRP with two mechanisms: link failure detection and local recovery. This proposal aims to detect and recover link failure as soon as it occurred by introducing a new join message. The simplicity, high ratio of packet delivery, and independency on a specific unicast protocol represent the strengths of ODMRP. In ODMRP selecting a forwarding nodes set for packet delivery required broadcasting a route request via the entire network. However, the ratio of node failures 353

4 increased when keeping single forwarding path, which are common in mobile ad hoc networks due to its dynamic nature. This research keeps the strengths of ODMRP and add extension to its standard in order to use alternative link in case of node mobility or route failures. Additionally, reducing the broadcasts which required in refreshing the node membership information. III. Proposed Routing Protocol ODMRP is soft state protocol as there is no explicit control messages that must be sent to join or leave the group. It depends on sending JOIN REQUEST packets to indicates it's intend in joining the group and it simply stops sending this packet when wants leaving the group. The proposed routing protocol based on ODMRP and its main goal is keeping the simplicity of ODMRP and reducing the required broadcasting packets which results in saving energy. In addition to, tackles the issue of node failure in case of a node leaves the multicast group or forwarding group. The proposed routing protocol aims minimize broadcasts packets via using unicast JOIN TABLE. In order to achieve this aim, a record named ROUTE will be created with each JOIN REQUEST. The ROUTE holds the path that JOIN REQUEST will pass through until reaching multicast receiver so it will updated with the address of each node it pass. A JOIN TABLE is unicast by multicast receiver(s) and forwarding group member(s) to multicast source instead of periodically broadcasting it using paths which are stored in ROUTE in each JOIN REQUEST. This modification will not affects the performance of routing protocol in terms of using not up-to-date paths because the multicast source broadcasts JOIN REQUEST periodically to keep the paths up-todate. Further, when member node of multicast group leaves the group, unwanted and unnecessary traffic may keep trying reach that node. On the other hand, when member node of forwarding group leaves the group, necessary traffic may cannot reach destination node. Proposed routing protocol suggests using (LEAVE MSG). LEAVE MSG will be sent by any forwarding group member or multicast receiver which intends leaving its group. This message provide an active communication with the multicast group source. The multicast source then removes any route(s) that passes the leaved forwarding group member or multicast receiver. Additionally, the multicast group source or any other node in multicast group or forwarding group will use alternative routes when it's required. The addition of the leave message (LEAVE MSG) in proposed routing protocol greatly reduces the leave latency compared to ODMRP. Further, the unwanted and unnecessary packets can be stopped much earlier. The proposed enhancement on ODMRP is described in the following steps: 1. JOIN REQUEST is broadcasted by multicast source to start establish the meshed multicast routes. JOIN REQUEST includes ROUTE which is a record used to save the path of broadcast request until reach the multicast receiver. JOIN REQUEST is broadcasted periodically in order to refresh the memberships of multicast group and updates the route. 2. When a non-duplicate JOIN REQUEST is received by node, it stores the ID of upstream node, updates the record ROUTE with its information and propagates the packet by rebroadcasting it again. If the JOIN REQUEST is duplicated and has different ROUTE, the node will deal with it as a non-duplicate request. 3. When a multicast receiver received the JOIN REQUEST packet, it adds or updates the entry of multicast source in its Member Table and saves ROUTE that includes path that this JOIN REQUEST followed. 4. When a multicast receiver received JOIN REQUEST packet from the same multicast source but with different ROUTE means another path, it saves this path as an alternative path. 5. Multicast receiver unicasts its JOIN TABLES to its neighbor(s) which are forwarding the JOIN REQUEST to the multicast receiver(s). The JOIN TABLES are sent via all paths that connect multicast source with receiver(s). This will notify the multicast source with all paths to that specific node. 354

5 6. When JOIN TABLE is received by a node, it sets the FG Flag as it realizes that it is one member of forwarding group, updates its JOIN TABLE and unicasts its own JOIN TABLE until it reaches the multicast source. 7. The multicast source receives multiple JOIN TABLEs from different routes. It uses the shortest path and keeps the rest as an alternative paths. 8. When any node from the multicast group or forwarding group decided to leave the group, it sends LEAVE MSG to multicast source and all its neighbors. 9. When a node in multicast group or forwarding group including multicast source receives LEAVE MSG, it removes all routes that passes this node and uses the alternative paths, which have been saved previously. Multicast source must take into its consideration that sometimes a node could be a multicast receiver and a member of forwarding group at the same time. Steps from 1 to 7 describes how the proposed enhancements of reduces using broadcasting packets by using the ROUTE record which holds the path between multicast source and a receivers. Using the LEAVE MSG is explained in steps 8 and 9. Although nodes need unicasting LEAVE MSG occasionally, it increase the reliability. Figure 1, 2 and 3 present the proposed improvement on ODMRP for multicast source, multicast receiver and a node in multicast group or forwarding group respectively. Start Broadcast, "JOIN REQUEST" Periodically Receiving non-duplicate "JOIN REQUEST" or has different ROUTE Use the shortest path Save all received routes to use them as an alternative paths Want to leave the group? No Yes Send LEAVE MSG to all nodes in multicast group End Figure 1. The proposed enhancement on ODMRP for Multicast Source 355

6 Start Waiting for JOIN REQUEST Receiving JOIN REQUEST? No Yes Receiving non-duplicate "JOIN REQUEST" or has different ROUTE Add to or update the entry of multicast source Member Table Save ROUTE Unicasts its JOIN TABLES to its neighbor(s) No Want to leave the group? Yes Send LEAVE MSG to multicast source and all its neighbors End Figure 2. The proposed enhancement on ODMRP for Multicast Receiver 356

7 Start Waiting for JOIN REQUEST or JOIN TABLE Receiving JOIN REQUEST? No Yes Receiving non-duplicate "JOIN REQUEST" or has different ROUTE Store the ID of upstream node, Update the record ROUTE Rebroadcast received packet (Propagate) No Receiving JOIN TABLE? Yes Set the FG Flag Update its JOIN TABLE Unicast its own JOIN TABLE No Want to leave the group Yes Send LEAVE MSG to multicast source and all its neighbors End Figure 3. The proposed enhancement on ODMRP for a node in multicast group or forwarding group 357

8 The proposed enhancement on ODMRP protocol take into its considerations that a node may be involved in multicast group and/or forwarding group. Figure 4 shows the strategy of the proposed enhancements. S node, which is the multicast source node, broadcast JOIN REQUEST to the entire network when it has multicast packet(s). Unicast reply Message S R1 F1 F2 R3 R2 Figure 4. The strategy of the Proposed Routing Protocol JOIN REQUEST include ROUTE information that updated with address of each node that forwards this broadcast request until reaching the multicast receiver. R1, R2 and R3, which are the multicast receivers, receive multiple JOIN REQUEST from the same multicast source but from different neighbors with different routes. For example R3 will receive (S-F1-R3) and (S-F2-R3) so it will realize that there are two paths connecting it with multicast source S. Then it uses these two paths to send its JOIN TABLE and saves both of them one as primary path and other as alternative path. After receiving JOIN REQUEST, R1, R2 and R3 unicast their JOIN TABLE to the multicast source node (S) through all the received paths. When F1 and F2 received JOIN TABLE of R1, R2 and R3, they set their FG Flag as they realize that they are members of forwarding group and forwarding JOIN TABLE to multicast source. Thus, instead of periodically broadcasting three JOIN TABLE messages to the neighbors, the proposed enhancements unicast 3 JOIN TABLEs to the neighbors. The multicast source saves all routes to the multicast receivers to use them when a node from multicast or forwarding groups leaves its group. For example if F2 leaves the multicast group, it unicasts LEAVE MSG to S and R3. Then, S1 and R3 use alternative path which is via F1(S-F1-R3) without need to refresh the saved routes. In figure 1 all nodes inside the bubble are required to achieve the multicast process successfully. IV. Simulated model The NS2 network simulator is used to implement the simulated model. This simulator is discrete event supports both wired and wireless communication networks [11]. The implemented scenario includes 50 wireless nodes moving randomly within a 1000mx1000m space. The applied parameters in suggested model is described in table seconds of simulation time is specified for each simulation execution. More than one runs with different locations of nodes are implemented for each proposed multicast group size and the average data is collected over these runs. The suggested scenario implemented with different size of 358

9 multicast group (5 members, 10 members, 15 members, 20 members, 25 members, and 30 members). The applied scenario includes one multicast source that establish one multicast group with different number of members as described previously. The selected number of multicast group member equal to 30% of total nodes. At the start of the simulation, the multicast group members join the multicast group. Then at randomly times, one member of multicast group leaves its group and one member of forwarding group leaves its group too. On a randomly bases, one node selects a destination and move to it with different speeds. This movement is repeated twice. The range of mobility speed is between 0 m/s to 50 m/s. Table 1. Used simulator values Parameter Bandwidth among nodes Delay in routes Message Length (broadcast) Message Length (Multicast) Message Length (Unicast) Number of receivers Receiving range Interval period Mobility model Mobility speed Simulation Time Value 2Mbytes 0ms 256 Bytes 512 Bytes/ 0.01 seconds 1024 Bytes 30% of total nodes 250 m 50.0 Seconds Random waypoint 10,20,30,40, 50 m/s Seconds V. Analysis Results To validate the proposed routing protocol, the packet delivery ratio and transmitted control bytes to delivered data byte ratio have been computed for both the proposed protocol and the original ODMRP protocol. The previous two metrics are computed depending on the simulator parameters expressed in table 1 in order to compare the performance of proposed improvements to the ODMRP. Figure 5 and figure 6 represent the computed two metrics of proposed improvements. While figure 7 and figure 8 represent the obtained results from applying ODMRP. In the proposed enhancements, the packet delivery ratio is improved and this reflect the advantage of using the strategy of LEAVE MSG. The transmitted control bytes to delivered data byte ratio is approximately the same as in ODMRP because nodes occasionally need to use LEAVE MSG. Since in the proposal, multicast receiver unicasts instead of broadcasts JOIN TABLES to its neighbors upon the multicast source request, the number of required broadcasts is minimized. Figure 6 shows the reduction in broadcast packets. When the number of nodes in entire network increased, the required number of broadcasts JOIN TABLES is increased. The relation between number of nodes in entire network and broadcast packets is positive relation. The reduction in broadcasts will save network resources in term of link availability and node energy. 359

10 transmitted control bytes to delivered data byte ratio Ratio of of Packet Delivery Journal University of Kerbala, Vol. 16 No.1 Scientific % 100% 98% 98% 96% 96% 94% 94% 92% 92% 90% 90% 88% 86% 84% 82% Ratio of Packet Delivery Ratio of Packet Delivery Speed 20of Nodes 30 Mobility (m/s) Speed of Nodes Mobility (m/s) 5 members 5 members 10 members 10 members 15 members 15 members 20 members 20 members 25 members 25 members 30 members 30 members Figure 5. Ratio of Packet Delivery in proposal Routing Protocol Ratio of Transmitted Control Bytes to Delivered Data Byte 70% 60% 50% 40% 30% 20% 10% 0% Speed of Nodes Mobility (m/s) 5 members 10 members 15 members 20 members 25 members 30 members Figure 6. Ratio of Transmitted Control Bytes to Delivered Data Byte in proposal Routing Protocol 360

11 transmitted control bytes to delivered data byte ratio Ratio of Packet Delivery Journal University of Kerbala, Vol. 16 No.1 Scientific % 98% Ratio of Packet Delivery 96% 94% 92% 90% 88% 86% 84% 5 members 10 members 15 members 20 members 25 members 30 members 82% Speed of Nodes Mobility (m/s) Figure 7. Ratio of Packet Delivery in ODMRP 70% Ratio of Transmitted Control Bytes to Delivered Data Byte 60% 50% 40% 30% 20% 10% 0% Speed of Nodes Mobility (m/s) 5 members 10 members 15 members 20 members 25 members 30 members Figure 8. Ratio of Transmitted Control Bytes to Delivered Data Byte in ODMRP Additionally, the chosen interval that separate two consecutive unicasting JOIN TABLEs affects the total number of required unicast packets. ODMRP proposed to choose timer value depending on the network environment factors such as traffic load and type, mobility speed and pattern, and channel capacity) [12]. Accordingly, selecting small values of route refresh interval guarantees fresh route and membership information but at the expense of network congestion as more packets are generated. Whereas, using large values of route refresh, guarantees producing less control traffic but nodes may not up dated with recent information of route and multicast membership [12]. 361

12 Number of Broadcasting Packets Journal University of Kerbala, Vol. 16 No.1 Scientific Number of Broadcasting Packets Number of nodes in Network ODMRP New Routing Protocol Figure 9. Number of Reply Broadcasting Packets Figure 9 shows the reduction in broadcasting packets that the proposal routing protocol achieved as it reduced the required broadcasting packets in ODMRP to half in average. This is attributed to using ROUTE record which facilitates replacing the broadcasting to refresh membership with unicast packets. VI. Conclusion This paper presents enhancement to ODMRP targets minimizing required broadcast packets and tackles the issue of node failures. These two issues consume the network resource extensively and minimize its reliability, because network congestion results is reducing the delivery ratio. Additionally, when a node in multicast group or forwarding group sent LEAVE-MSG to its group the multicast routes can be managed smoothly and fast to find alternative paths or avoid sending unnecessary traffic. The proposed improvements consist of two modifications: first using ROUTE record to save all paths between multicast source and receivers then send unicast message using these paths instead of broadcast message to refresh the membership of nodes in multicast group and forwarding group. Second, when any node in the multicast group or forwarding group intends leaving its group, it must alert its group about its leaving. NS2 simulator is used to validate these improvements and the results show reducing in the required broadcasting packets to the half of the required broadcasting packets in ODMRP. In addition to, enhancing the packet delivery ratio so the reliability of the network is improved. This reflects the speed and smooth of multicast paths managing process which takes action as soon as a node leaves the network. Further, the proposed enhancement takes into its consideration the strengths of ODMRP representing by its simplicity, high packet delivery ratio, and non-dependency on a specific unicast protocol. It is add new ROUTE record and one control message LEAVE-MEG which is used occasionally by nodes upon their leaving the network. 362

13 VII. References [1] Sung-Ju Lee, Mario Gerla, and Ching-Chuan Chiang, On-Demand Multicast Routing Protocol, Journal: Mobile Networks and Applications, Volume 7 Issue 6, December 2002, Pages , Kluwer Academic Publishers Hingham, MA, USA. [2] Thomas Kunz and Ed Cheng, "Multicasting in ad-hoc networks: Comparing MAODV and ODMRP", Proceedings of the Workshop on Ad hoc Communications, Bonn, Germany, September [3] Yao Zhao, Leiming Xu, Meilin Shi, On-Demand Multicast Routing Protocolwith Multipoint Relay (ODMRP-MPR) in Mobile Ad-Hoc Network, Computer Modeling and Simulation, ICCMS '10. Second International Conference, Sanya, Hainan, China, 2010 [4] Dhammika P athirana, Thesis: RODMRP - resilient on demand multicast routing protocol, Rochester Institute of Technology, RIT Scholar Works, 2007 [5] P. I. Basarkod and Sunilkumar S. Manvi, On-demand QoS and Stability Based Multicast Routing in Mobile Ad Hoc Networks, Journal of Telecommunications & Information Technology;2014, Vol Issue 3, p98, [6] Sanneboina Prasanthi, I Balavenkateswarlu, and S Amarnath Babu, Implementing ODMRP (on Demand Multicast Routing Protocol) in Mantes Using Stable Link Approach, International Journal of Engineering Research and Development e-issn: X, p-issn : X, ww.ijerd.com Volume 4, Issue 11 (November 2012), PP [7] Shahram Jamali, SODMRP: Stable on-demand multicast routing protocol, Przeglad Elektrotechniczny, January [8] Y.X Hu, Y.F Jia, Improvement of Wireless Multicast Routing with Energy-efficiency Based on ODMRP, IEEE CNMT, [9] R. Ghafouri, M. Fathy, LF-RDTODMRP: A Robust and Efficient On-Demand Multicast Routing Protocol for Ad Hoc Networks, IEEE 14th CSICC, [10] N. Naderan-Tahan, A. Darehshoorzadeh, M. Dehghan, ODMRP-LR: ODMRP with Link Failure Detection and Local Recovery Mechanism, IEEE ICIS, [11] ns-2 User Information, [online Available]: [12] Sung-JuLee, Thesis: Routing and Multicasting Strategies in Wireless Mobile Ad hoc Networks, University of California Los Angeles,